home *** CD-ROM | disk | FTP | other *** search
- Path: au.wang.com!chianina!usenet
- From: Jeremy Lee <jeremy_lee@ccmail.au.wang.com>
- Newsgroups: comp.lang.c
- Subject: Re: (no subject)
- Date: 15 Jan 1996 22:25:22 GMT
- Organization: WANG
- Message-ID: <4dek8i$qjf@chianina.au.wang.com>
- References: <1996Jan15.174105.22784@tellab5.tellabs.com>
- NNTP-Posting-Host: hellfire.au.wang.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1B sun4)
- X-URL: news:1996Jan15.174105.22784@tellab5.tellabs.com
-
- Joe Toth <toth@tellabs.com> wrote:
- [...]
- >The Scenario;
- [...]
- > I perform my functions and set
- > the signals to allow for a proper return to the code when the interrupt
- > occurred. For some reason, the 'bell' character is output to the terminal
- > which causes the audio/screen flash on the monitor. The standard code
- > is executing in a system call (read) when the SIGALRM is generated.
- [...]
-
- alarm() can't do that. read() can't do that. You MUST have something queued
- in the output buffer that has not been flushed by any of the canonical
- processing until the interrupt occurs. Try flushing the buffer ?TCIOFLUSH?
- (termios.h) via an ioctl. While this might make the problem go away, it
- would be better to find out whats ready to print and where it came from.
- --
- ----------------------------------------------------------------------
- Jeremy Lee
- Wang Australia
- jeremy_lee@ccmail.au.wang.com
-
-